SherbyNet - /page/wikibook/entry.mu

Micron Document

<!DOCTYPE html>

<title>Two-phase commit protocol</title>

</head>

<span id="openzim-page-title" class="mw-page-title-main"><span class="mw-page-title-main">Two-phase commit protocol</span></span>

</h1>

</header>

/* start https://en.wikipedia.org/ */

.mw-parser-output .hatnote{font-style:italic}.mw-parser-output div.hatnote{padding-left:1.6em;margin-bottom:0.5em}.mw-parser-output .hatnote i{font-style:normal}.mw-parser-output .hatnote+link+.hatnote{margin-top:-0.5em}@media print{body.ns-0 .mw-parser-output .hatnote{display:none!important}}

/* end https://en.wikipedia.org/ */

</style><div role="note" class="hatnote navigation-not-searchable">"2PC" redirects here. For the play in American and Canadian football, see <a href="Two-point_conversion" title="Two-point conversion">Two-point conversion</a>. For the cryptographic protocol, see <a href="Commitment_scheme" title="Commitment scheme">Commitment scheme</a>. For the concurrency control, see <a href="Two-phase_locking" title="Two-phase locking">Two-phase locking</a>.</div>

<p>In <a href="Transaction_processing" title="Transaction processing">transaction processing</a>, <a href="Database" title="Database">databases</a>, and <a href="Computer_networking" class="mw-redirect" title="Computer networking">computer networking</a>, the <b>two-phase commit protocol</b> (<b>2PC</b>, <i>tupac</i>) is a type of <a href="Atomic_commit" title="Atomic commit">atomic commitment protocol</a> (ACP). It is a <a href="Distributed_algorithm" title="Distributed algorithm">distributed algorithm</a> that coordinates all the processes that participate in a <a href="Distributed_transaction" title="Distributed transaction">distributed atomic transaction</a> on whether to <a href="Commit_(data_management)" title="Commit (data management)">commit</a> or abort (roll back) the transaction. This protocol (a specialised type of <a href="Consensus_(computer_science)" title="Consensus (computer science)">consensus</a> protocol) achieves its goal even in many cases of temporary system failure (involving either process, network node, communication, etc. failures), and is thus widely used.<sup id="cite_ref-bernstein1987_1-0" class="reference"><a href="#cite_note-bernstein1987-1"><span class="cite-bracket">[</span>1<span class="cite-bracket">]</span></a></sup><sup id="cite_ref-weikum2001_2-0" class="reference"><a href="#cite_note-weikum2001-2"><span class="cite-bracket">[</span>2<span class="cite-bracket">]</span></a></sup><sup id="cite_ref-Bern2009_3-0" class="reference"><a href="#cite_note-Bern2009-3"><span class="cite-bracket">[</span>3<span class="cite-bracket">]</span></a></sup>

However, it is not resilient to all possible failure configurations, and in rare cases, manual intervention is needed to remedy an outcome. To accommodate recovery from failure (automatic in most cases) the protocol's participants use <a href="Server_log" class="mw-redirect" title="Server log">logging</a> of the protocol's states. Log records, which are typically slow to generate but survive failures, are used by the protocol's <a href="Recovery_procedure" title="Recovery procedure">recovery procedures</a>. Many protocol variants exist that primarily differ in logging strategies and recovery mechanisms. Though usually intended to be used infrequently, recovery procedures compose a substantial portion of the protocol, due to many possible failure scenarios to be considered and supported by the protocol.

</p><p>In a "normal execution" of any single <a href="Distributed_transaction" title="Distributed transaction">distributed transaction</a> (i.e., when no failure occurs, which is typically the most frequent situation), the protocol consists of two phases:

</p>

<ol><li>The commit-request phase (or voting phase), in which a coordinator process attempts to prepare all the transaction's participating processes (named participants, cohorts, or workers) to take the necessary steps for either committing or aborting the transaction and to vote, either "Yes": commit (if the transaction participant's local portion execution has ended properly), or "No": abort (if a problem has been detected with the local portion), and</li>

<li>The commit phase, in which, based on voting of the participants, the coordinator decides whether to commit (only if all have voted "Yes") or abort the transaction (otherwise), and notifies the result to all the participants. The participants then follow with the needed actions (commit or abort) with their local transactional resources (also called recoverable resources; e.g., database data) and their respective portions in the transaction's other output (if applicable).</li></ol>

<p>The two-phase commit (2PC) protocol should not be confused with the <a href="Two-phase_locking" title="Two-phase locking">two-phase locking</a> (2PL) protocol, a <a href="Concurrency_control" title="Concurrency control">concurrency control</a> protocol.

</p>

<div class="mw-heading mw-heading2"><h2 id="Assumptions">Assumptions</h2></div>

<p>The protocol works in the following manner: one node is a designated coordinator, which is the master site, and the rest of the nodes in the network are designated the participants. The protocol assumes that:

</p>

<ol><li>there is <a href="Stable_storage" title="Stable storage">stable storage</a> at each node with a <a href="Write_ahead_logging" class="mw-redirect" title="Write ahead logging">write-ahead log</a>,</li>

<li>no node crashes forever,</li>

<li>the data in the write-ahead log is never lost or corrupted in a crash, and</li>

<li>any two nodes can communicate with each other.</li></ol>

<p>The last assumption is not too restrictive, as network communication can typically be rerouted. The first two assumptions are much stronger; if a node is totally destroyed then data can be lost.

</p><p>The protocol is initiated by the coordinator after the last step of the transaction has been reached. The participants then respond with an agreement message or an abort message depending on whether the transaction has been processed successfully at the participant.

</p>

<div class="mw-heading mw-heading2"><h2 id="Basic_algorithm">Basic algorithm</h2></div>

<div class="mw-heading mw-heading3"><h3 id="Commit_request_(or_voting)_phase">Commit request (or voting) phase</h3></div>

<ol><li>The coordinator sends a query to commit message to all participants and waits until it has received a reply from all participants.</li>

<li>The participants execute the transaction up to the point where they will be asked to commit. They each write an entry to their undo log and an entry to their <a href="Redo_log" title="Redo log">redo log</a>.</li>

<li>Each participant replies with:</li></ol>

<dl><dd><dl><dd><dl><dd><b>either</b> an <i>agreement message (</i>participant votes Yes to commit), if the participant's actions succeeded;</dd>

<dd><b>or</b> an <i>abort message</i> (participant votes No to commit), if the participant experiences a failure that will make it impossible to commit.</dd></dl></dd></dl></dd></dl>

<div class="mw-heading mw-heading3"><h3 id="Commit_(or_completion)_phase">Commit (or completion) phase</h3></div>

<div class="mw-heading mw-heading4"><h4 id="Success">Success</h4></div>

<p>If the coordinator received an agreement message from all participants during the commit-request phase:

</p>

<ol><li>The coordinator sends a commit message to all the participants.</li>

<li>Each participant completes the operation, and releases all the locks and resources held during the transaction.</li>

<li>Each participant sends an acknowledgement to the coordinator.</li>

<li>The coordinator completes the transaction when all acknowledgements have been received.</li></ol>

<div class="mw-heading mw-heading4"><h4 id="Failure">Failure</h4></div>

<p>If any participant votes No during the commit-request phase (or the coordinator's timeout expires):

</p>

<ol><li>The coordinator sends a rollback message to all the participants.</li>

<li>Each participant undoes the transaction using the undo log, and releases the resources and locks held during the transaction.</li>

<li>Each participant sends an acknowledgement to the coordinator.</li>

<li>The coordinator undoes the transaction when all acknowledgements have been received.</li></ol>

<div class="mw-heading mw-heading4"><h4 id="Message_flow">Message flow</h4></div>

<pre>Coordinator Participant

QUERY TO COMMIT

-------------------------------->

VOTE YES/NO prepare*/abort*

<-------------------------------

commit*/abort* COMMIT/ROLLBACK

-------------------------------->

ACKNOWLEDGEMENT commit*/abort*

<--------------------------------

end

</pre>

<p>An * next to the record type means that the record is forced to stable storage.<sup id="cite_ref-mohan1986_4-0" class="reference"><a href="#cite_note-mohan1986-4"><span class="cite-bracket">[</span>4<span class="cite-bracket">]</span></a></sup>

</p>

<div class="mw-heading mw-heading2"><h2 id="Disadvantages">Disadvantages</h2></div>

<ol><li>The greatest disadvantage of the two-phase commit protocol is that it is a blocking protocol.</li>

<li>If the coordinator fails permanently, some participants will never resolve their transactions: After a participant has sent an agreement message as a response to the commit-request message from the coordinator, it will block until a commit or rollback is received.</li>

<li>A two-phase commit protocol cannot dependably recover from a failure of both the coordinator and a cohort member during the commit phase. If only the coordinator had failed, and no cohort members had received a commit message, it could safely be inferred that no commit had happened. If, however, both the coordinator and a cohort member failed, it is possible that the failed cohort member was the first to be notified, and had actually done the commit. Even if a new coordinator is selected, it cannot confidently proceed with the operation until it has received an agreement from all cohort members, and hence must block until all cohort members respond.</li></ol>

<div class="mw-heading mw-heading2"><h2 id="Implementing_the_two-phase_commit_protocol">Implementing the two-phase commit protocol</h2></div>

<div class="mw-heading mw-heading3"><h3 id="Common_architecture">Common architecture</h3></div>

<p>In many cases the 2PC protocol is distributed in a computer network. It is easily distributed by implementing multiple dedicated 2PC components similar to each other, typically named <a href="Transaction_manager" class="mw-redirect" title="Transaction manager">transaction managers</a> (TMs; also referred to as 2PC agents or Transaction Processing Monitors), that carry out the protocol's execution for each transaction (e.g., <a href="The_Open_Group" title="The Open Group">The Open Group</a>'s <a href="X/Open_XA" title="X/Open XA">X/Open XA</a>). The databases involved with a distributed transaction, the participants, both the coordinator and participants, register to close TMs (typically residing on respective same network nodes as the participants) for terminating that transaction using 2PC. Each distributed transaction has an ad hoc set of TMs, the TMs to which the transaction participants register. A leader, the coordinator TM, exists for each transaction to coordinate 2PC for it, typically the TM of the coordinator database. However, the coordinator role can be transferred to another TM for performance or reliability reasons. Rather than exchanging 2PC messages among themselves, the participants exchange the messages with their respective TMs. The relevant TMs communicate among themselves to execute the 2PC protocol schema above, "representing" the respective participants, for terminating that transaction. With this architecture the protocol is fully distributed (does not need any central processing component or data structure), and scales up with number of network nodes (network size) effectively.

</p><p>This common architecture is also effective for the distribution of other <a href="Atomic_commit" title="Atomic commit">atomic commitment protocols</a> besides 2PC, since all such protocols use the same voting mechanism and outcome propagation to protocol participants.<sup id="cite_ref-bernstein1987_1-1" class="reference"><a href="#cite_note-bernstein1987-1"><span class="cite-bracket">[</span>1<span class="cite-bracket">]</span></a></sup><sup id="cite_ref-weikum2001_2-1" class="reference"><a href="#cite_note-weikum2001-2"><span class="cite-bracket">[</span>2<span class="cite-bracket">]</span></a></sup>

</p>

<div class="mw-heading mw-heading3"><h3 id="Protocol_optimizations">Protocol optimizations</h3></div>

<p><a href="Database" title="Database">Database</a> research has been done on ways to get most of the benefits of the two-phase commit protocol while reducing costs by protocol optimizations<sup id="cite_ref-bernstein1987_1-2" class="reference"><a href="#cite_note-bernstein1987-1"><span class="cite-bracket">[</span>1<span class="cite-bracket">]</span></a></sup><sup id="cite_ref-weikum2001_2-2" class="reference"><a href="#cite_note-weikum2001-2"><span class="cite-bracket">[</span>2<span class="cite-bracket">]</span></a></sup><sup id="cite_ref-Bern2009_3-1" class="reference"><a href="#cite_note-Bern2009-3"><span class="cite-bracket">[</span>3<span class="cite-bracket">]</span></a></sup> and protocol operations saving under certain system's behavior assumptions.

</p>

<div class="mw-heading mw-heading4"><h4 id="Presumed_abort_and_presumed_commit">Presumed abort and presumed commit</h4></div>

<p>Presumed abort or Presumed commit are common such optimizations.<sup id="cite_ref-weikum2001_2-3" class="reference"><a href="#cite_note-weikum2001-2"><span class="cite-bracket">[</span>2<span class="cite-bracket">]</span></a></sup><sup id="cite_ref-Bern2009_3-2" class="reference"><a href="#cite_note-Bern2009-3"><span class="cite-bracket">[</span>3<span class="cite-bracket">]</span></a></sup><sup id="cite_ref-mohan1983_5-0" class="reference"><a href="#cite_note-mohan1983-5"><span class="cite-bracket">[</span>5<span class="cite-bracket">]</span></a></sup> An assumption about the outcome of transactions, either commit, or abort, can save both messages and logging operations by the participants during the 2PC protocol's execution. For example, when presumed abort, if during system recovery from failure no logged evidence for commit of some transaction is found by the recovery procedure, then it assumes that the transaction has been aborted, and acts accordingly. This means that it does not matter if aborts are logged at all, and such logging can be saved under this assumption. Typically a penalty of additional operations is paid during recovery from failure, depending on optimization type. Thus the best variant of optimization, if any, is chosen according to failure and transaction outcome statistics.

</p>

<div class="mw-heading mw-heading4"><h4 id="Tree_two-phase_commit_protocol">Tree two-phase commit protocol</h4></div>

<p>The <a href="Tree_(data_structure)" class="mw-redirect" title="Tree (data structure)">Tree</a> 2PC protocol<sup id="cite_ref-weikum2001_2-4" class="reference"><a href="#cite_note-weikum2001-2"><span class="cite-bracket">[</span>2<span class="cite-bracket">]</span></a></sup> (also called Nested 2PC, or Recursive 2PC) is a common variant of 2PC in a <a href="Computer_network" title="Computer network">computer network</a>, which better utilizes the underlying communication infrastructure. The participants in a distributed transaction are typically invoked in an order which defines a tree structure, the invocation tree, where the participants are the nodes and the edges are the invocations (communication links). The same tree is commonly utilized to complete the transaction by a 2PC protocol, but also another communication tree can be utilized for this, in principle. In a tree 2PC the coordinator is considered the root ("top") of a communication tree (inverted tree), while the participants are the other nodes. The coordinator can be the node that originated the transaction (invoked recursively (transitively) the other participants), but also another node in the same tree can take the coordinator role instead. 2PC messages from the coordinator are propagated "down" the tree, while messages to the coordinator are "collected" by a participant from all the participants below it, before it sends the appropriate message "up" the tree (except an abort message, which is propagated "up" immediately upon receiving it or if the current participant initiates the abort).

</p><p>The Dynamic two-phase commit (Dynamic two-phase commitment, D2PC) protocol<sup id="cite_ref-weikum2001_2-5" class="reference"><a href="#cite_note-weikum2001-2"><span class="cite-bracket">[</span>2<span class="cite-bracket">]</span></a></sup><sup id="cite_ref-raz1995_6-0" class="reference"><a href="#cite_note-raz1995-6"><span class="cite-bracket">[</span>6<span class="cite-bracket">]</span></a></sup> is a variant of Tree 2PC with no predetermined coordinator. It subsumes several optimizations that have been proposed earlier. Agreement messages (Yes votes) start to propagate from all the leaves, each leaf when completing its tasks on behalf of the transaction (becoming ready). An intermediate (non leaf) node sends ready when an agreement message to the last (single) neighboring node from which agreement message has not yet been received. The coordinator is determined dynamically by racing agreement messages over the transaction tree, at the place where they collide. They collide either at a transaction tree node, to be the coordinator, or on a tree edge. In the latter case one of the two edge's nodes is elected as a coordinator (any node). D2PC is time optimal (among all the instances of a specific transaction tree, and any specific Tree 2PC protocol implementation; all instances have the same tree; each instance has a different node as coordinator): By choosing an optimal coordinator D2PC commits both the coordinator and each participant in minimum possible time, allowing the earliest possible release of locked resources in each transaction participant (tree node).

</p>

<ul><li><a href="Three-phase_commit_protocol" title="Three-phase commit protocol">Three-phase commit protocol</a></li>

<li><a href="Paxos_algorithm" class="mw-redirect" title="Paxos algorithm">Paxos algorithm</a></li>

<li><a href="Raft_(algorithm)" title="Raft (algorithm)">Raft algorithm</a></li>

<li><a href="Two_Generals'_Problem" title="Two Generals' Problem">Two Generals' Problem</a></li></ul>

<div class="mw-heading mw-heading2"><h2 id="References">References</h2></div>

/* start https://en.wikipedia.org/ */

.mw-parser-output .reflist{margin-bottom:0.5em;list-style-type:decimal}@media screen{.mw-parser-output .reflist{font-size:90%}}.mw-parser-output .reflist .references{font-size:100%;margin-bottom:0;list-style-type:inherit}.mw-parser-output .reflist-columns-2{column-width:30em}.mw-parser-output .reflist-columns-3{column-width:25em}.mw-parser-output .reflist-columns{margin-top:0.3em}.mw-parser-output .reflist-columns ol{margin-top:0}.mw-parser-output .reflist-columns li{page-break-inside:avoid;break-inside:avoid-column}.mw-parser-output .reflist-upper-alpha{list-style-type:upper-alpha}.mw-parser-output .reflist-upper-roman{list-style-type:upper-roman}.mw-parser-output .reflist-lower-alpha{list-style-type:lower-alpha}.mw-parser-output .reflist-lower-greek{list-style-type:lower-greek}.mw-parser-output .reflist-lower-roman{list-style-type:lower-roman}

/* end https://en.wikipedia.org/ */

</style><div class="reflist">

<li id="cite_note-bernstein1987-1"><span class="mw-cite-backlink">^ <a href="#cite_ref-bernstein1987_1-0"><sup><i><b>a</b></i></sup></a> <a href="#cite_ref-bernstein1987_1-1"><sup><i><b>b</b></i></sup></a> <a href="#cite_ref-bernstein1987_1-2"><sup><i><b>c</b></i></sup></a></span> <span class="reference-text"><a href="Phil_Bernstein" title="Phil Bernstein">Philip A. Bernstein</a>, Vassos Hadzilacos, Nathan Goodman (1987): <a rel="nofollow" class="external text" href="http://research.microsoft.com/en-us/people/philbe/ccontrol.aspx"><i>Concurrency Control and Recovery in Database Systems</i></a>, Chapter 7, Addison Wesley Publishing Company, <style data-mw-deduplicate="TemplateStyles:r1238218222">

/* start https://en.wikipedia.org/ */

.mw-parser-output cite.citation{font-style:inherit;word-wrap:break-word}.mw-parser-output .citation q{quotes:"\"""\"""'""'"}.mw-parser-output .citation:target{background-color:rgba(0,127,255,0.133)}.mw-parser-output .id-lock-free.id-lock-free a{background:url("./mw/Lock-green.svg")right 0.1em center/9px no-repeat}.mw-parser-output .id-lock-limited.id-lock-limited a,.mw-parser-output .id-lock-registration.id-lock-registration a{background:url("./mw/Lock-gray-alt-2.svg")right 0.1em center/9px no-repeat}.mw-parser-output .id-lock-subscription.id-lock-subscription a{background:url("./mw/Lock-red-alt-2.svg")right 0.1em center/9px no-repeat}.mw-parser-output .cs1-ws-icon a{background:url("./mw/Wikisource-logo.svg")right 0.1em center/12px no-repeat}body:not(.skin-timeless):not(.skin-minerva) .mw-parser-output .id-lock-free a,body:not(.skin-timeless):not(.skin-minerva) .mw-parser-output .id-lock-limited a,body:not(.skin-timeless):not(.skin-minerva) .mw-parser-output .id-lock-registration a,body:not(.skin-timeless):not(.skin-minerva) .mw-parser-output .id-lock-subscription a,body:not(.skin-timeless):not(.skin-minerva) .mw-parser-output .cs1-ws-icon a{background-size:contain;padding:0 1em 0 0}.mw-parser-output .cs1-code{color:inherit;background:inherit;border:none;padding:inherit}.mw-parser-output .cs1-hidden-error{display:none;color:var(--color-error,#d33)}.mw-parser-output .cs1-visible-error{color:var(--color-error,#d33)}.mw-parser-output .cs1-maint{display:none;color:#085;margin-left:0.3em}.mw-parser-output .cs1-kern-left{padding-left:0.2em}.mw-parser-output .cs1-kern-right{padding-right:0.2em}.mw-parser-output .citation .mw-selflink{font-weight:inherit}@media screen{.mw-parser-output .cs1-format{font-size:95%}html.skin-theme-clientpref-night .mw-parser-output .cs1-maint{color:#18911f}}@media screen and (prefers-color-scheme:dark){html.skin-theme-clientpref-os .mw-parser-output .cs1-maint{color:#18911f}}

/* end https://en.wikipedia.org/ */

</style><a href="ISBN_(identifier)" class="mw-redirect" title="ISBN (identifier)">ISBN</a> <bdi>0-201-10715-5</bdi></span>

</li>

<li id="cite_note-weikum2001-2"><span class="mw-cite-backlink">^ <a href="#cite_ref-weikum2001_2-0"><sup><i><b>a</b></i></sup></a> <a href="#cite_ref-weikum2001_2-1"><sup><i><b>b</b></i></sup></a> <a href="#cite_ref-weikum2001_2-2"><sup><i><b>c</b></i></sup></a> <a href="#cite_ref-weikum2001_2-3"><sup><i><b>d</b></i></sup></a> <a href="#cite_ref-weikum2001_2-4"><sup><i><b>e</b></i></sup></a> <a href="#cite_ref-weikum2001_2-5"><sup><i><b>f</b></i></sup></a></span> <span class="reference-text"><a href="Gerhard_Weikum" title="Gerhard Weikum">Gerhard Weikum</a>, Gottfried Vossen (2001): <a rel="nofollow" class="external text" href="http://www.elsevier.com/wps/find/bookdescription.cws_home/677937/description#description"><i>Transactional Information Systems</i></a>, Chapter 19, Elsevier, <a href="ISBN_(identifier)" class="mw-redirect" title="ISBN (identifier)">ISBN</a> <bdi>1-55860-508-8</bdi></span>

</li>

<li id="cite_note-Bern2009-3"><span class="mw-cite-backlink">^ <a href="#cite_ref-Bern2009_3-0"><sup><i><b>a</b></i></sup></a> <a href="#cite_ref-Bern2009_3-1"><sup><i><b>b</b></i></sup></a> <a href="#cite_ref-Bern2009_3-2"><sup><i><b>c</b></i></sup></a></span> <span class="reference-text">Philip A. Bernstein, Eric Newcomer (2009): <a rel="nofollow" class="external text" href="http://www.elsevierdirect.com/product.jsp?isbn=9781558606234"><i>Principles of Transaction Processing</i>, 2nd Edition</a> <a rel="nofollow" class="external text" href="https://web.archive.org/web/20100807151625/http://www.elsevierdirect.com/product.jsp?isbn=9781558606234">Archived</a> 2010-08-07 at the <a href="Wayback_Machine" title="Wayback Machine">Wayback Machine</a>, Chapter 8, Morgan Kaufmann (Elsevier), <a href="ISBN_(identifier)" class="mw-redirect" title="ISBN (identifier)">ISBN</a> <bdi>978-1-55860-623-4</bdi></span>

</li>

<li id="cite_note-mohan1986-4"><span class="mw-cite-backlink"><b><a href="#cite_ref-mohan1986_4-0">^</a></b></span> <span class="reference-text"><a href="C._Mohan" title="C. Mohan">C. Mohan</a>, Bruce Lindsay and R. Obermarck (1986): <a rel="nofollow" class="external text" href="http://dl.acm.org/citation.cfm?id=7266">"Transaction management in the R* distributed database management system"</a>,<i>ACM Transactions on Database Systems (TODS)</i>, Volume 11 Issue 4, Dec. 1986, Pages 378 - 396</span>

</li>

<li id="cite_note-mohan1983-5"><span class="mw-cite-backlink"><b><a href="#cite_ref-mohan1983_5-0">^</a></b></span> <span class="reference-text"><a href="C._Mohan" title="C. Mohan">C. Mohan</a>, Bruce Lindsay (1985): <a rel="nofollow" class="external text" href="http://portal.acm.org/citation.cfm?id=850772">"Efficient commit protocols for the tree of processes model of distributed transactions"</a>,<i>ACM SIGOPS Operating Systems Review</i>,

19(2), pp. 40-52 (April 1985)</span>

</li>

<li id="cite_note-raz1995-6"><span class="mw-cite-backlink"><b><a href="#cite_ref-raz1995_6-0">^</a></b></span> <span class="reference-text">Yoav Raz (1995): <a href="https://doi.org/10.1007/3-540-58907-4_14" class="extiw external" title="doi:10.1007/3-540-58907-4 14">"The Dynamic Two Phase Commitment (D2PC) protocol "</a>,<i>Database Theory — ICDT '95</i>, <i>Lecture Notes in Computer Science</i>, Volume 893/1995, pp. 162-176, Springer, <a href="ISBN_(identifier)" class="mw-redirect" title="ISBN (identifier)">ISBN</a> <bdi>978-3-540-58907-5</bdi></span>

</li>

</ol></div></div></div><div><div class="zim-footer">

This article is issued from <a class="external text" title="Last edited on 2025-07-21" href="https://en.wikipedia.org/wiki/?title=Two-phase_commit_protocol&oldid=1301697357">Wikipedia</a>. The text is available under <a class="external text" href="https://creativecommons.org/licenses/by-sa/4.0/deed.en">Creative Commons Attribution-Share Alike 4.0</a> unless otherwise noted. Additional terms may apply for the media files.

</div>

</div></div>

</div>

</main>

</div>

</body></html>